\section{Approach}
\label{sec:approach}
%\section{OUR APPROACH TO OPTIMIZING DECISION MAKING IN XACML}
 
Our approach relies on splitting the PDP policy based on a refactoring process. The objective is to improve 
the performance of the request evaluation, while preserving the access control architecture.
Since the decision making process involves the evaluation of all the rules in the global policy, we propose to reduce 
the number of rules that have to be evaluated for a given request issued by a PEP. This boils down to the idea that the policy evaluation is 
faster when there are few rules to be processed to compute the decision. Obviously, a PDP that has to check 2 rules will be much faster that a PDP that checks 200 rules. However,
 what happens in a request evaluation process is that for a given access control request, some rules are evaluated in the global policy whereas some of those rules are not
 applicable to the request. Starting from this observation, we propose a scenario in which only the relevant rules for a given request will be evaluated
 in the decision making process, this scenario is based on a refactoring operation supported by our prototype tool. It automates the policy splitting 
into smaller policies based on attribute values combination. 
\\
This section starts by providing more technical details illustrating our refactoring process. Then, its shows 
the splitting criterion that can be selected in order preserve the access control architecture.

\subsection{XACML Policy Refactoring Process}
%In \cite{clustering}, the authors decompose the global policy into a set of policies where each set gathers the subjects that share common applicable
%rules whereas in \cite{decomposition} the proposed approach involves evaluating all the boolean expressions \cite{boolean} for all the rules in the 
%policy and clustering all the rules having the same boolean expression.
%the PDP component which fetches the necessary policies and necessary attributes for decision making.

Our conceptual approach to improve the performance in the XACML decision making process focuses on splitting the PDP policy.
We propose to transform a policy P into smaller policies \normalsize $P_{SC_{w}}$ where each policy conforms to a Splitting Criteria $SC_{w}$.
An $SC_{w}$ defines the set of target elements, that can be considered to classify all the rules into sets of rules having the 
same attribute values. $w$ denotes the number of target elements that have to be considered conjointly for aggregating rules into
 a unified set based on specific target elements selection.

An XACML policy can be refactored considering one target element. In this case a policy can be split into a set of policies where the 
rules have the same subject, resource, or action. Rules can also be aggregated considering two splitting criteria like $<Subject, Action>$ or
 $<Action, Resource>$, in this setting, a policy will be transformed into a set of smaller policies where rules in the resulting policies have the same 
couple of target elements. 
We can go further in our grouping strategy when using $P_{SC_{w}}$ whose 
rules match a specific triplet of resource, action and subject. Table I shows all the combinations of the splitting criteria according to the target elements.

\begin{table}[h!]
\centering
\setlength{\extrarowheight}{6 pt}
\begin{tabular}{|l|c|}   
\hline  \rowcolor{black} 
 \bf
\textcolor  {white}{Splitting Criteria}& \bf \textcolor{white}{Possible Configurations}\\ \hline
 
$SC_{1}$& {$<Subject>, <Resource>, <Action>$}\\ \hline

$SC_{2}$& {$<Subject,Action>, <Subject,Resource>$}\\&{$<Resource,Action>$}\\  \hline

$SC_{3}$& {$<Subject,Resource,Action>$}\\ \hline
\end{tabular}
\caption{Splitting Criteria}\label{table1}\end{table}

In our approach, we propose an access control architecture built with multiple (PDPs), where each PDP enforces
a policy that complies with a certain splitting criterion. A mapping table data structure is used to define the 
mapping between potential request target elements and corresponding smaller policies $P_{SC_{w}}$.
We propose a schema in which a given PEP interacts with a dispatcher that receives the PEP's request, fetches the mapping table and extracts 
the suitable PDP that has to provide a response for given request. Figure \ref{decomposition}.a gives an overview of this architecture in the 
case $SC_{1}=<Subject>$ is chosen as a splitting criterion. In this scenario, the PEP builds the request and forwards it to an intermediary component, ``the dispatcher''
 that receives the XACML request and fetches the subject's request attributes. Then, the PDPs that are relevant to the subjects attributes are located based on the mapping table, 
and used to provide the XACML response to the PEP. 

\begin{figure}[!h]
\begin{center}
\includegraphics[width=9cm]{pep-pdp}
\caption{Request processing: (a)-PDP splitting based on target elements: $SC_{1}=<Subject>$/(b)-
PDP splitting based on system functions}
\label{decomposition}
\end{center}
\end{figure}
%With the objective of highlighting some relevant considerations that have to be taken in the decomposition process:
\begin{large}
\end{large}

To illustrate our approach, we present some examples that take into consideration the XACML language features:
\begin{itemize}
\item The XACML policy 1 presented in Figure \ref{xacml-decomposition} is a simple XACML policy whose target elements, which are
 defined for the global XACML policy are \normalsize $<AnyResource>$, $<AnySubject>$, $<AnyAction>$, thus the global policy is applicable 
to any subjects, any resources and any actions.
The refactoring of this policy according to the splitting criterion 
$SC_{1}=<Subject>$ consists in splitting the XACML policy into the sub-policies 2 and 3 where each sub-policy groups the rules 
that are relevant for each subject (Alice and Bob in this case). XACML policies 2 and 3 are the two resulting policies.

\item
In the previous example, the target element has a simple structure, however target elements 
in XACML may have a structure which is more complex, if they encapsulate the structure of target elements Match.
As stated in \cite{oasis}, $<ResourceMatch>$, $<SubjectMatch>$, $<ActionMatch>$ 
elements define a set of target elements related entities that has to match at the decision level with the context element in 
an access control request. If a structure of target element match is used, it encapsulates the following elements:

\begin{itemize}
\item A MatchId element which defines a matching function, like ``string-equal'' in the example of Figure 
\ref{multi-attributes}, besides an attribute value.
\item An AttributeDesignator that identifies the attributes values of the target element.
\end{itemize}

In case we have a structure of target elements that conforms to the structure shown in Figure \ref{multi-attributes},
two target elements, are equals if they have respectively equal sets of MatchId, Attribute values, and AttributeDesignators. 
In case there is a difference in one of the mentioned sets, the two target elements are considered different and thus dispatched into different policies during the refactoring process.


\begin{figure}[!h]
\centering
\includegraphics[width=9cm]{exemple1}
\caption{XACML policy refactoring process example: $SC_{1}=<Subject>$ }
\label{xacml-decomposition}
\end{figure}

\end{itemize}
\begin{figure}[!h]
\begin{center}
\includegraphics[width=8cm, height=3.5cm]{xacml-match}
\caption{Multi-attributes Target Element}
\label{multi-attributes}
\end{center}
\end{figure}

\subsection{Architecture Model Preservation: PEP-PDP Synergy}
We consider the different splitting criteria that we have identified in the previous section and we propose to select the splitting 
criteria that enables preserving the synergy property in the access control architecture.
The selected splitting criteria should enable to have multiple policies encapsulated in several PDPs 
where each PDP is mapped to a single PEP.
A PEP-PDP mapping is observable through the code at application level. In fact, a deep analysis of the PEPs and 
the corresponding triggered rules, enables to explicitly describe this mapping. At the application level, every PEP is mapped to a 
service implementation through a system method call that triggers a decision making process by activating some specific rules in a single 
PDP.

The code below is taken from \cite{legacy}, this code excerpt shows an example of a PEP which is implemented by the method 
checkSecurity, this method calls the class SecurityPolicyService that initiates the PDP component.
\begin{algorithmic}
\begin{algorithm}[!h]
%\caption{System security function that describes a PEP enforcement}
   \STATE public void borrowBook(User user, Book book)
   \STATE throws SecuritPolicyViolationException {
   \STATE   // call to the security service
\STATE \hspace{0.5cm} \textbf{ServiceUtils.checkSecurity(user,
\STATE LibrarySecurityModel.BORROWBOOK\_METHOD,
\STATE LibrarySecurityModel.BOOK\_VIEW);}
\STATE ContextManager.getTemporalContext());
    \STATE  // call to business objects
    \STATE  // borrow the book for the user
\STATE \hspace{0.5cm} book.execute(Book.BORROW, user);
\STATE      // call the dao class to update the DB
\STATE \hspace{0.5cm} bookDAO.insertBorrow(userDTO, bookDTO);}
\end{algorithm}
\end{algorithmic}

An analysis of this code reflects that this function will trigger exclusively all the rules organized by the couple (Action, Resource) for 
the subject given as input parameter. This is due to the call of the following methods: LibrarySecurityModel.BORROWBOOK\_METHOD and 
LibrarySecurityModel.BOOK\_VIEW.

%%%%%
Conceptually, we propose to transform the global policy into subsets of rules where each subset can be mapped to a PEP.
In this setting, each single request initiated by a specific PEP will have its corresponding evaluating PDP conforming to the PEP-PDP matching. 
This implies that the different method calls initiated by PEPs are identified at the code level at the decision making time and mapped to their 
corresponding PDPs. A mapping table is used to establish the link between each PEP implementation and the corresponding rules 
encapsulated in a given PDP. A general schema for this approach is presented in Figure \ref{decomposition}.b.

Figure \ref{synergy} synthesizes the concept of synergy between PEPs and corresponding PDPs. In the worse case, splitting the initial PDP into multi-PDPs may lead to a non-synergic system: a PEP may send its requests to several PDPs. The PDP, which receives a request is only known at runtime. Such a resulting architecture breaks the PEP-PDP synergy and the conceptual 
simplicity of the initial architecture model. The splitting criteria which lead to such a non-synergic architecture is not a valid refactoring: 
the complexity induced by the splitting, makes the maintenance and evolution of the system more difficult to manage.
In the best case, the refactoring preserves the simplicity of the initial architecture, by keeping a many-to-one association from PEPs to PDPs. A given request evaluation 
triggered by one PEP will always be handled by the same PDP. Operationally, the request evaluation process will involve 
one XACML policy file. In this case, the refactoring is valid, since its does not impact the conceptual architecture of the system.

\begin{figure}[!h]
\begin{center}
\includegraphics[width=9cm]{synergy}
\caption{Synergic system / Non synergic system}
\label{synergy}
\end{center}
\end{figure}

Depending on the system architecture, establishing this mapping may require to identify all the enforcements points in an application, and to 
track the different method calls 
triggered from these specific enforcement calls to map them to the relevant access control rules.  
In this work, we analyze the best splitting criteria in our empirical studies, for these empirical studies, we know in advance our different PEPs and their corresponding relevant rules. 
%We propose to identify automatically the different PEPs in a future work, however for this work, we can identify easily the different PEPs as we know in
% advance that system functions are implemented through the consideration of (Resource, Action) target elements thus a policy refactoring according 
%to system function is assimilated to policy refactoring according to the splitting criteria SC$_{1}=<$Action,Resource$>$. 

Our empirical results, presented in section~\ref{sec:experiment}, have shown that adopting a policy refactoring based on system functions, as a refactoring strategy, enables to reduce the decision making time. 
%Our empirical results have constantly shown that adopting a policy refactoring based on system functions, as a refactoring strategy, enables to reduce the decision making time. 
This strategy takes into consideration how the PEPs interact with the PDPs, how the rules are activated across the system, and preserve
the architectue 	since we preserve the cardinality relation between PEPs and PDPs.
 
As depicted in Figure \ref{overallprocess}, the refactoring process is automated and starts by specifying and creating the XACML file which 
will be split by our tool according to a specified SC that can be chosen by an access control stakeholder. Afterwards, the policies are included in the 
framework that supports our approach. For every change in the access control policy, the initial policy is updated and 
split again in order to be included again in the framework.

\begin{figure}[!h]

\begin{center}
\includegraphics[width=8.5cm, height=8cm]{Overall-process}
\caption{Overview of the process of defining and deploying Access Control Policies}
\label{overallprocess}
\end{center}
\end{figure} 
From a point of view of the system administration, maintaining and updating the access control policies is completely a standalone and simple
 process. The input is usually a centralized XACML policy. This input remains the same than before the access control performance issue is tackled.
Our process is transparent in the sense that it does not impact the existing functional aspects of the access control management system, 
for system administrators, who have to update the policy fequently and have to manage various dimensions of access control 
systems such the scalability and maintainability.